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Abstract 

The future of space mission designing will be 
dramatically different from the past. Formerly, 
performance-driven paradigms emphasized data return 
with cost and schedule being secondary issues. Now and 
in the future, costs are capped and schedules fixed — these 
two variables must be treated as independent in the design 
process. Accordingly, JPL has redesigned its design 
process. 

At the conceptual level, design times have been reduced 
by properly defining the required design depth, improving 
the linkages between tools, and managing team dynamics. 
In implementation-phase design, system requirements 
will be held in crosscutting models, linked to subsystem 
design tools through a central database that captures the 
design and supplies needed configuration management 
and control. Mission goals will then be captured in 
timelining software that drives the models, testing their 
capability to execute the goals. 

Metrics are used to measure and control both processes 
and to ensure that design parameters converge through 
the design process within schedule constraints. This 
methodology manages margins controlled by acceptable 
risk levels. Thus, teams can evolve risk tolerance (and 
cost) as they would any engineering parameter. This new 
approach allows more design freedom for a longer time, 
which tends to encourage revolutionary and unexpected 
improvements in design. 

Introduction and Summary 


three years’ performance are presented and discussed. 
This same basic process is now being installed at the 
implementation phase design level. We describe its 
model-driven design infrastructure, which uses a central 
database for design capture and configuration 
management, and its team-based design process. A 
simple model predicts savings in design time that can be 
realized. 

Overview of the Space Mission Design 
Process 

The majority of space missions are designed in two 
distinct phases, the conceptual phase and the 
implementation phase. In the conceptual phase a design 
is prepared for customer approval, either through a 
proposal process or as a sponsor-funded study. 
Conceptual designs are typically developed to some 
limited level of engineering depth, as specified by some 
stated need for accuracy of estimated cost and schedule. 
They are usually inspired by a set of science or 
technology goals. A traditional approach to concept 
development would begin with the assembly of a design 
team, who, through a series of regular meetings or work 
sessions, dissects the goals into system requirements on 
hardware, software, operations teams and the like. These 
are given to designers, who may spend several weeks 
developing designs and providing cost information. 
Costs may be grass roots (developed by the designers 
based on costs of parts and labor), parametric (developed 
through a software model that uses cost of past designs as 
a basis and estimated from some design parameters that 
historically drive cost), or both. 


Engineering design processes are undergoing tremendous 
change in the 1990s. Cost and schedule consciousness, 
especially in the field of space mission design, has led to 
several initiatives to produce fundamental process 
change. The NASA Administrator has recently challenged 
NASA centers and their contractors to lead US industry in 
this revolution. The response to this challenge has led to 
fundamental redesign of the space mission design process 
[1], and work has begun to specify an underlying 
architecture [2]. 

In this paper we review a concept for revolutionary 
change to the space mission design process. At the 
conceptual design level, the basics of this process are 
installed and iryoutine use. Metrics based on more than 


Conceptual designs are incorporated into a proposal 
submitted to the sponsor for evaluation. If the design is 
sound and the cost acceptable, the winning proposer is 
awarded the job and implementation, the second design 
phase, begins. 

As in the conceptual phase, implementation-phase designs 
are driven by requirements derived from goals. In the 
implementation phase, however, some method of 
managing and controlling requirements is necessary, as 
there are usually frequent updates. Traditionally, system 
requirements are captured and held in a set of documents 
which are parsed into increasingly lower level 
requirements until they are at the level where a single 


engineering team can design to them. As the design 
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proceeds, requirements are either accepted or modified, 
and designers proceed to implement the design as soon as 
all requirements are accepted. This process involves 
testing hardware and software as it is developed, and it 
concludes with the integration of ail elements into a 
whole for final testing and launch of the mission. Testing 
the system as a whole is seldom successful the first time, 
and both design errors and fabrication errors are 
uncovered and returned to the appropriate designer or 
fabricator for rework. The last and generally most 
exciting phase of the mission is operations, where the 
system is used to carry out the science or other goals, and 
data are returned and analyzed. 

This basic design scheme has been used for many space 
missions for many years and has produced many 
successes. However, recent pressure to make the design 
process faster, better, and cheaper has inspired 
revolutionary changes. Among these are process-based 
organization, model-based design [3,4], revised 
leadership and training, and system modeling [2, 4, 5, 6]. 
Concepts already in use in industrial systems design have 
also been adopted for use in space missions. In particular 
the concept of concurrency has received attention as a 
significant time saver in teams [7,8,9,10,1 1]. 

Effectiveness of teams and their relationship to the 
surrounding organizational culture have been discussed in 
many environments [e.g., 12,13,14]. Methods to measure 
and increase innovation in teams are reviewed in [15], 
and specific metrics for innovation are available [16,17]. 
The design and measurement of teaming relationships are 
shown to be an important subject when improving 
efficiency of a human or human-machine combined 
process. 

The Conceptual Phase Design Process 

Traditionally, small, dedicated design teams produce 
conceptual studies. Each proposal is produced by a 
unique team that develops and implements its own unique 
process. Typically the teams meet weekly to report 
status, review action items, and establish new actions and 
deliverables. However, the emphasis on different aspects 
of the design/proposal differs among the teams (e.g., 


cost/performance trades, ground systems/operations 
concepts, mechanical design, electrical design), as does 
the analytical tools employed to address these issues. 
Furthermore, since each team member serves on only one 
or a few such teams, there is little opportunity to apply 
lessons learned and little incentive to develop tools and 
methods that could improve the capabilities of future 
proposal teams. In addition, since the teams are usually 
funded with internal development funds, resources are not 
available to develop new tools or tools that could 
integrate the outputs of each discipline represented on the 
team. As a result, analytical efforts are disjointed and not 
integrated with cost estimates, which are usually 
attempted only after the primary design variables have 
been specified. 

Thus, both the cost and quality of the proposals generated 
by this process are highly dependent on the team 
membership, especially the team leader. Some proposals 
might be of very high quality, others not. The principal 
characteristics of this approach are as follows. First, a 
dedicated, self-sufficient team designs each project from 
the ground up. Each product is, therefore, unique and has 
the quality of being produced by hand. Second, 
approaches to the concept definition, the work breakdown 
and cost breakdown structures are likewise unique. 
Third, the tools used to defme missions are unique and 
often generated explicitly for each mission. For example, 
a mission concept requires study of the trajectory by 
which a spacecraft may travel to its destination. Some 
trajectory options will allow a more massive spacecraft, 
while others may feature a shorter transit time. Software 
tools are required to discover options, compare them, and 
optimize them. Similarly, spacecraft subsystem tradeoffs 
require tools to manage the comparison of more powerful 
options against less massive ones. 

In 1994, in recognition of the nation’s changing economic 
and strategic environment, JPL undertook a re- 
engineering of our project and system engineering 
processes [18]. The fundamental nature of the change 
was from a design-to-performance methodology to one of 
design-to-cost, but the re-engineering team also described 
other desirable shifts. Those applicable to concept-phase 
studies are shown in Table 1. 


Table 1. Changes to the Conceptual Design Process (adapted from [18]) 


FROM 

TO 

Performance-driven design 

Cost-driven design 

Sequential design 

Concurrent design 

Hierarchical process 

Consensus process 

Deferred problem resolution 

Real-time problem resolution 

Paper data exchange 

Electronic data exchange 

Stand-alone tools 

Integrated tools 

Limited design-space exploration 

Comprehensive design-space exploration 

Zero-width interfaces 

Zones of interaction 

Requirements-driven approach 

Hardware (capabilities)-driven approach 

Subsystem engineering models 

System engineering models 



Results have been (I) the creation of an environment and 
a team to apply multidisciplinary design optimization, 
with full consideration of schedule, mission operations, 
and cost; (2) the ability to use consensus process for real- 
time problem resolution; (3) the creation of a set of linked 
tools that facilitate concurrent design by passing pertinent 
parameters quickly from one member to all others and 
eliminate the re-entry of designs between design tools; 
and (4) the use of cost models to quickly demonstrate the 


fiscal effect of major design changes while still in the 
concurrent environment. 

The environment created for conceptual design differs 
from the traditional environment in a number of ways. 
The physical environment, called the Project Design 
Center or PDC, is designed so that engineers can work in 
a meeting room at the same time that they work in a more 
private office (Figure 1). 



Figure 1. The Project Design Center Physical Layout 

In the room are sixteen seats, each occupied by an of the design, a related programmatic function, or a 
individual responsible for a particular functional element support function (Table 2). A long table, at which 







customers and sponsors sit and discuss design details with 
members of the design team, occupies the center. Team 
members are only a 180-degree chair turn away from a 
workstation and telephone at which they can access any 
tool necessary for his or her design work. At the front of 


the room are three projection screens on which any of the 
workstations screens can be shown, or on which remote 
sites can be seen, or on which summaries of the state of 
the design can be reviewed. 


Table 2. Team X Positions 


Team/Study Leader 

Systems 

Power 

Thermal 

Structures 

Programmatics 


Science 

Cost 

Telecom-Hardware 
Telecom-Systems 
Ground Systems 
Instruments 


CDS 

ACS 

Mission Design 
Propulsion 
Graphics Design 
Documentarian 


Engineers’ workstations are networked to each other 
using an interconnected system that supplies latest design 
data to them as the design and the related conversations 
about the central table mature in concert with each other. 
In this environment, a team that is also significantly 
different operates. The Advanced Projects Design Team, 
universally called “Team X,” was formed from members 
of JPL’s technical staff who had participated in previous 
space mission design and in the missions themselves. 
Functional design elements common to space missions 
are each represented by an engineer and a backup. Cost 
is included as a primary design element. A study leader 
orchestrates discussions, and a documentarian is 
responsible for capture of design trades made, rationales 
for direction, etc. Individuals assigned by JPL program 
offices, who are considered a customer to whom the 
service is provided, bring new mission concepts to the 
team. Team X participates in three-hour concurrent 
engineering sessions with the study manager to develop 
the concept to a level of detail sufficient to proceed with a 
formal proposal. The customer meets with the study 
leader to define the basics of the idea (e.g., target body, 
cost target, scope of the design effort, risk philosophy) 
sufficiently to allow some preliminary homework to be 
done. 

Next, sessions are held with the full team. Team X 
sessions start with a description of the science objectives 
and how they might fit into the perceived opportunity. 
Through discussions with the customer, design team 
members derive a set of mission requirements that will 
meet the mission objectives as well as possible within 
cost. Although each study will vary, a typical Team X 
session might proceed as follows. The session may begin 
with a team estimate of spacecraft mass and propulsion 
requirements appropriate to the mission type based on 
prior experience. Scientific observation objectives are 
established (e. g., images to be taken, samples to be 
returned), and an instrumentation complement is defined. 
Acquisition data rates are totaled for the instruments. An 
instrument pointing control requirement is determined 
and passed to the attitude control engineer. A data 
collection strategy is derived from the measurement 
objectives, and acquisition data rates are determined. A 
data return strategy is worked out and required onboard 


data storage is determined. After telecommunications 
antenna size and pointing control requirements are 
calculated, the attitude control system (ACS) is sized and 
the ACS propellant requirement determined. Onboard 
computer requirements are collected and a data system is 
chosen. 

As the various required functions are defined, preliminary 
allocations are made to functional elements (although the 
importance of correct/final functional allocation is 
restricted to the development of a target cost). 
Prototypical subsystem components (star scanners, 
computer processors, propulsion systems and the like) are 
chosen by the team consistent with the risk philosophy. 
Component masses and power requirements are totaled 
by the spreadsheet. For each component chosen, a 
technology readiness level (TRL) is assigned based on the 
maturity of the component development at the estimated 
launch date. Calculated power requirements are used to 
size the power system, and the thermal control system is 
defined. The refined spacecraft dry mass total is then 
used to calculate required propellant mass. A packaging 
approach is discussed and a drawing of a possible 
spacecraft structure is produced. The total mass and 
volume requirements are used to make a final choice of 
launch vehicle. 

The information system engineer prepares a preliminary 
mission operations concept. At this early stage, the 
operations concept will be very high level and contain 
many assumptions. Developing the mission operations 
concept early in the study phase enables the minimization 
of life cycle costs as well as the determination of the 
effectiveness of using existing system capabilities. The 
earlier the mission operations concept is developed, the 
more leverage there is for influencing the operability of 
the entire mission system, including the space element. 
The development of the mission operations concept is 
most beneficial when done in parallel with the spacecraft 
design and there is a tight coupling between the two 
efforts. 

An appropriate parametric cost model is chosen for the 
class of mission, and selected requirements that have 
traditionally been strong cost drivers are fed to it. The 
cost model quickly produces an estimated cost and an 



estimate of the uncertainty in that cost based on the TRLs 
and other factors. This cost estimate is used to iterate 
design requirements and, if necessary, mission goals until 
the cost goal is met. Similarly, mass or power totals can 
be quickly iterated against a fixed cost, launch vehicle, or 
other fixed requirement. Importantly, broad trade spaces 
involving ground equipment, flight equipment, science 
objectives and cost can be addressed in the concurrent 
environment. Infusion of new technology can be balanced 
against anticipated schedule and cost impacts. After an 
agreement is reached on a design point each design 
engineer can provide a grass roots estimate of the cost of 
his or her function. Those estimates are totaled, and 
deviations of the grass roots cost from the modeled cost 
are then reviewed and justified. 

Team X sessions are summarized by the team members 
and the documentarian into a final report during the 
session itself, using a distributed word processor available 
to all positions. The final form of the design is captured 
in the report and into a database for later recovery. Text 
from the final report is made available to the customer for 
preparation of a proposal. 

Conceptual Phase Metrics 


process. Figure 2 shows the related metrics. Previously, 
JPL had been able to complete at most ten conceptual 
designs in one year, requiring 26 weeks to complete and 
at a typical cost of $250k. With the revised process, 
engineering designs for more than fifty mission concepts 
per year are generated in less than two weeks each, 
requiring total funds less than $75k. In 1996, 45 such 
designs were completed; in subsequent years this number 
was increased to 50 to 75, often requiring two instances 
of Team X operating in parallel. This increased capacity 
has been used to enable the creation of candidate mission 
roadmaps, allowing NASA to choose among proposed 
mission sets rather than single missions. Some of this 
time saved is that previously required to assemble a team, 
relieve them of other duties, establish procedures, and 
other bureaucratic necessities, but other efficiencies have 
come from shortened communication loops, computer-to- 
computer data exchanges, and online report writing. An 
additional advantage is that the Team X approach has 
enabled design cycle times measured in minutes or hours 
rather than weeks. Thus the option exists to allow much 
broader design space exploration and optimization if 
desired. 


Team X has been in existence for over three years and is 
now an established part of our conceptual phase design 
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Figure 2. Conceptual Phase Design Metrics 


Implementation Phase Design 

Most of the actual design work is done following 
acceptance of a mission, in the implementation phase. 
Compression of this design process has also received 
attention in the past few years. Tools and tool linkages 


that compress this phase are discussed in [1] and [2], and 
an overview of a redesigned process has been elaborated 
in [5]. 

We have implemented and are evaluating such a system 
for implementation phase design, with the teaming outline 



and database structure shown in Figure 3. In this scheme, 
high-level mission constraints are defined by the mission 
team using the conceptual design described in the 
previous section of this paper. The mission team includes 
such roles as the project scientist, mission engineer, and 
flight and ground system engineers. These are captured 
in the timelining tool APGEN [20] as rule-based 
statements of events that must happen together, must not 
happen together, must follow each other, etc. The team 


loads rough estimates of power, data, and other resources 
into APGEN for each event. Mission science teams and 
mission designers create a mission scenario that describes 
in high-level terms what activities a mission is to 
accomplish in APGEN. The program captures the 
timeline and, given the resource estimates, makes plots of 
resource usage as a function of time. A mission scenario 
that is roughly consistent with constraints and resources is 
output from APGEN. 


SCIENCE TEAM 
NEGOTIATION 



MISSION TEAM 

• MANIPULATES SCENARIO AND PAD 1 

• KEEPS BALANCE BETWEEN COST, 
SCHEDULE. SCENARIO 

• REACTS TO INCOHERENCIES WHEN 
THEY CAUSE VIOLATION OF 
SYSTEM LEVEL DESIGN 


SYSTEM 

DESIGN 


v 


SYSTEM 
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DESIGN TEAM 

• CREATES DETAILED DESIGN 
AT SUBSYSTEM LEVEL 

• REACTS TO INCOHERENCES 
WITHIN LIMITS 


SUBSYSTEM 

DESIGN 



TEST RESULTS 
AND 

INCOHERENCES 


TEST TEAM 

• IMPORTS DESIGN, INTEGRATES 
AND TESTS 

(AS MODELS, BREADBOARDS 
SOFTWARE OR HARDWARE) 

• REPORTS INCOHERENCES TO 
DESIGN TEAM 


(b) TEAMING SCHEME 


Figure 3. Data and Teaming Flow for Implementation 


The conceptual design and mission scenario are used to 
create high-level system requirements and a system 
design, which are stated in modeling software following 
[4]. Parameters describing the design are revised from the 
conceptual design and stored in a central database called 
the Project Attributes Database (PAD). Parameters are 
linked to system models, and a product breakdown 
structure is created that attaches system level parameters 
(e.g., system mass, cost, and power) to subsystem 
parameters (e.g., individual subsystem masses, costs, and 
power). The system models are then attached to the 
APGEN output and executed to ensure that the scenario 
can be executed by the designed system. For example, 
power requirements and power sources are balanced with 


battery capacity, data sinks and sources are balanced 
against onboard storage capability and data downlinks, 
and the like. Note that cost and schedule are regarded as 
system models and are estimated and balanced like any 
other engineering parameter. The cost model, for 
example, may be a parametric model based on past 
missions that uses some parameters from the PAD to 
continuously update both life cycle cost and cost profile 
by year as the design cycle proceeds, or it may be a 
combination of parametric and grassroots methods as in 
the conceptual phase. 

When requirements and scenario are in balance, the 
mission team’s attention shifts to the scenario as 







subsystem design begins. First, constraints are refined in 
AFGEN in response to the capabilities of the system 
design. Then the mission scenario is updated and 
sufficient detail is added to make the scenario useful as a 
source of test procedures. 

To begin subsystem design, the mission team releases the 
design to the design team, whose job it is to design the 
subsystems required in the system design. Design 
parameters and resource allocations are extracted from 
the PAD and models more behavioral in nature are 
created of subsystems. In the PAD, a set of parameters 
parallel to the system design specifications is created so 
that subsystem design values can be entered for 
comparison. In addition, the number of parameters is 
expanded to include subsystem designs, some of which 
will have no system equivalent. Subsystem models are 
delivered to the test team, who operates in the system 
integration and test environment to integrate the modeled 
subsystems and test them. The test team uses test 
procedures drawn either from requirements or from the 
mission scenario to test these models in the first instance 
of system test (which in the previous paradigm does not 
occur until much later). For each test cycle, another 
parallel set of parameters is created in the PAD to 
represent actual measurements. Test results are used to 
discover test failures or “incoherencies,” which are 
returned to the design team for design correction. If the 
design team is unable to resolve the incoherency within 
the allocations present in the PAD, the incoherency is 
returned to the mission team. For example, a subsystem 
engineer in the design team may find that the design 
requires more power than anticipated, and that there is no 
solution within that subsystem — this is known in the trade 
as a “design pushback” on requirements. Such 
incoherencies are treated as an imbalance in the system 
models and resolved by readjusting the scenario, 
rebalancing the system level requirements, or both. Note 
that in this rebalancing cost and schedule are continuously 
updated and obvious, and can thus be treated as 
independent variables. 

The cycle described above is repeated as new system 
designs translate into new constraints, scenarios and 
subsystem designs. As the design matures, subsystem 
models of designs are replaced by breadboards and flight 
or ground hard- and software, and the test environment 
proceeds from testing of models through testing of 
hybrids of models/breadboards/hardware to final test of 
flight and ground equipment. Thus final integration and 
test becomes simply another in a series of integrations 
which lead from models to flight and ground hardware 
and software. Although unproven, our expectation is that 
design errors will be uncovered much earlier as the 
models are tested together, and final integration and test 
will be able to concentrate on the discovery of fabrication 
errors, thus reducing the number of redesigns required. 

Imbalances at the system level can, and often do, occur 
for external reasons. The mission sponsor sometimes 
directs the project to reduce its life cycle cost or readjust 
costs by year. The science team may respond to recent 


scientific results or other needs by changing the scenario, 
or new findings about the environment (radiation levels, 
for example) may make the mission’s task different in 
some way. Whereas past philosophy has been to resist 
such changes (freeze the requirements), experience has 
shown that they are common and probably inevitable. In 
our proposed scheme, at each rebalance by the mission 
team (which can be brought on by either a new system 
design or a new scenario or both) the latest updates from 
both system and scenario are used, thus accommodating 
changes to either. Similarly, management reviews are 
accomplished by witnessing the satisfaction of the 
scenario by the system models. 

In summary, we expect four major advantages of this 
scheme over traditional design practice. First, the use of 
three concurrent teams provides a naturally shorter design 
cycle. Traditional schemes have design cycles limited by 
weekly meeting schedules, interspersed with manual 
(telephone, e-mail or paper) data exchanges. This 
scheme’s concurrent teams do not need weekly meetings, 
and they exchange data through the PAD, enabling design 
cycle times measured in days. Second, the enabling of 
fluid requirements encourages creative solutions that 
reach outside of existing requirements and allow more 
trade-space exploration during detailed design. Third, 
more fluid requirements will allow and account for both 
sponsor-inspired changes and subsystem design 
pushback. Finally, the use of models allows early system 
test and design error detection, saving rework and 
reserving final integration and test time for discovery of 
fabrication errors. In the conceptual design phase we have 
also noted increased employee satisfaction, higher team 
innovation and more team loyalty, and we expect similar 
advantages in the implementation phase designs as well. 

Conclusion 

This paper describes two new processes for space mission 
design. The revised processes involve fundamental 
changes in the integration of design tools, the design 
process, and the team structures. In the conceptual design 
phase, a facility that promotes concurrent engineering 
incorporates linked design tools and redesigned process 
featuring management of team discussions. This new 
process has resulted in significant favorable changes in 
design time, cost and quality. A proposed change to the 
design scheme in implementation phase design has 
potential for similar improvements in time and quality. 

The research described in this paper was carried out by 
the Jet Propulsion Laboratory, California Institute of 
Technology, under a contract with the National 
Aeronautics and Space Administration. 
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